JumpingBattle 스트리밍 플랫폼 기술 의사 결정
JumpingBattle은 실제 전국 약 30개 매장에서 사용되는 서비스였기 때문에, 안정성과 경제성을 최우선으로 고려하며 설계되었습니다.
개요
해당 스트리밍 시스템은 2025년 가을 기준 전국 약 30개 매장에서 실제 사용되는 것을 전제로 제작되었습니다.
따라서 단순 기능 구현보다는:
- 안정적인 파일 제공 구조
- 운영 비용 절감
- 서버 유지 부담 최소화
- 만료 파일 관리 자동화
등과 같은 운영 구조를 우선적으로 고려하며 설계하였습니다.
특히 다운로드 및 스트리밍 기능은 단순 파일 제공 수준이 아니라, Signed URL 기반 접근 제어와 만료 정책 등을 함께 포함하는 방향으로 구성되었습니다.
배포 구조 및 운영
해당 시스템은 AWS Lambda 기반 서버리스 구조로 배포되었습니다.
초기에는 EC2 기반 구조 또한 고려하였으나, 전국 단위 매장 운영 환경에서 발생할 수 있는 유지 비용과 관리 부담을 줄이기 위하여 서버리스 구조를 우선적으로 검토하였습니다.
Flask 기반으로 작성된 코드는 Zappa를 통하여 Lambda 환경에 배포되도록 구성하였으며, 이를 통해:
- Lambda 환경에 맞는 구조 변환
- API Gateway 연결
- CloudWatch 기반 로그 검수
등을 함께 관리할 수 있도록 설계하였습니다.
특히 Zappa를 활용함으로써, Flask 기반 구조를 유지하면서도 비교적 단순한 형태로 서버리스 환경에 배포할 수 있었습니다.
Zappa를 활용한 Lambda 배포
만일 해당 프로젝트를 현재(2026.05) 다시 진행한다면, GitHub Actions를 활용한 배포 자동화 또한 함께 구성할 것 같습니다.
하지만 당시에는 실제 매장 환경에서 사용되는 기능 구현과 운영 안정성을 우선적으로 확보하는 것이 중요하다고 판단하였습니다.
따라서 배포 과정 전체를 자동화하기보다는, Flask 기반 코드를 Lambda 환경에 비교적 빠르게 배포할 수 있도록 Zappa를 활용한 서버리스 구조를 우선적으로 선택하였습니다.
해당 구조를 통해:
- Lambda 환경에 맞는 구조 변환
- API Gateway 생성
- CloudWatch 기반 로그 검수
등을 비교적 단순한 형태로 관리할 수 있었습니다.
또한 Flask 기반 구조를 그대로 유지하면서도, 별도의 서버를 직접 관리하지 않고 AWS Lambda 환경에 배포할 수 있었다는 점 역시 운영 부담을 줄이는 데에 도움이 되었습니다.
Flask 기반 서버리스 구조
1인 개발 환경에서 Flask를 우선적으로 사용한 가장 큰 이유는 구현 속도와 구조 단순성 때문이었습니다.
해당 프로젝트는:
- 로그인 기반 사용자 관리
- 복잡한 ORM 구조
- 대규모 관리자 시스템
등이 필요한 상황은 아니었기 때문에, Django보다는 보다 가볍고 빠르게 구조를 설계할 수 있는 Flask를 선택하였습니다.
또한 Flask 기반 코드를 Zappa를 통해 Lambda 환경에 비교적 단순하게 배포할 수 있다는 점 역시 중요한 선택 이유 중 하나였습니다.
이를 통해 별도의 서버를 직접 관리하기보다는, 기능 구현과 운영 안정성 확보에 더욱 집중할 수 있도록 구조를 구성하였습니다.
[1]Flask 기반 구조는 현재 프로젝트의 목적과 서버리스 환경에 가장 적합하다고 판단하였습니다.
SpringBoot는 엔터프라이즈 환경에서 강점을 가지는 프레임워크였지만, Lambda 환경에서는 비교적 많은 설정과 추가 구조가 필요하였습니다.
반면 Flask는 1인 개발 및 서버리스 구조와의 연결 편의성이 높아 현재 프로젝트에 더욱 적합하다고 판단하였습니다.
운영 과정에서 고려한 문제
운영 과정에서 가장 먼저 고려한 부분은 무분별한 다운로드 시도와 같은 악의적인 접근, 그리고 사용자 의도와 다른 예외 상황들이었습니다.
특히 실제 매장 환경에서는:
- 잘못된 파일 접근
- 존재하지 않는 파일 요청
- 오탈자로 인한 접근 실패
- 만료된 파일 다운로드 시도
등과 같은 문제가 반복적으로 발생할 가능성이 있다고 판단하였습니다.
따라서 단순히 파일을 제공하는 수준이 아니라, 해당 파일의 존재 여부와 만료 상태 등을 사이트 렌더링 이전 단계에서 우선 검수할 수 있도록 구조를 구성하였습니다.
세부적인 운영 구조와 예외 처리 흐름은 하위 문서에서 추가로 후술합니다.
Signed URL 기반 접근 제어
해당 구조에서 가장 우선적으로 고려한 부분은, Firebase Storage에 대한 직접 접근을 제한하는 것이었습니다.
만약 Storage URL이 그대로 외부에 노출될 경우:
- 파일 링크 공유
- 비인가 다운로드
- 만료 정책 우회
- 무분별한 트래픽 발생
등과 같은 문제가 발생할 가능성이 있다고 판단하였습니다.
따라서 사용자가 Storage에 직접 접근하는 구조 대신, 서버 측에서 Signed URL을 생성하여 일정 시간 동안만 제한적으로 접근할 수 있도록 구성하였습니다.
해당 구조를 통해:
- 다운로드 접근 제한
- 스트리밍 접근 제어
- 만료 시간 기반 제한
- 직접 URL 노출 방지
등을 함께 관리할 수 있도록 설계하였습니다.
파일 검수 및 예외 처리
실제 운영 환경에서는 사용자의 의도와 다른 접근 요청이나 단순 오탈자와 같은 문제 또한 반복적으로 발생할 수 있다고 판단하였습니다.
따라서 단순히 파일을 반환하는 수준이 아니라:
- 존재하지 않는 파일 요청
- 이미 만료된 파일 접근
- 잘못된 경로 접근
- 파일명 오탈자
등에 대한 검수 과정을 우선적으로 수행할 수 있도록 구조를 구성하였습니다.
또한 사용자가 문제 원인을 보다 쉽게 이해할 수 있도록, 오류 상황별로 다른 흐름과 메시지를 제공할 수 있도록 설계하였습니다.
만료 파일 관리 구조
파일 관리 구조에서 가장 중요하게 고려한 부분 중 하나는, 만료된 파일의 지속적인 누적 문제였습니다.
특히 실제 운영 환경에서는 장기간 사용되지 않는 파일이 계속 남아 있을 경우:
- Storage 비용 증가
- 파일 관리 복잡도 증가
- 잘못된 접근 가능성 증가
등과 같은 문제가 발생할 가능성이 있다고 판단하였습니다.
따라서 Firebase Functions를 활용하여 만료일자가 지난 파일을 자동으로 삭제할 수 있도록 구성하였습니다.
또한 자동 삭제 실패 상황 또한 고려하여, 만료 상태를 별도로 검수할 수 있는 흐름 역시 함께 설계하였습니다.
각주
Flask 기반 구조는 현재 프로젝트의 목적과 서버리스 환경에 가장 적합하다고 판단하였습니다.
SpringBoot는 엔터프라이즈 환경에서 강점을 가지는 프레임워크였지만, Lambda 환경에서는 비교적 많은 설정과 추가 구조가 필요하였습니다.
반면 Flask는 1인 개발 및 서버리스 구조와의 연결 편의성이 높아 현재 프로젝트에 더욱 적합하다고 판단하였습니다.